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(54) Context controller having instruction-based time slice task switcliing capability and 
processor employing the same 



(57) A context controller for managing multitasking 
in a processor and a method of operating the same. In 
one embodiment, the context controller includes: (1) a 
time slice instruction counter that counts a number of 
instructions executed with respect to a given back- 
ground task and (2) a background task controller that 



cyclicly executes a context corresponding to another 
background task when the number of instructions exe- 
cuted equals a dynamically-programmable time slice 
value. 
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Description 

Technical Field Of The Invention 

[0001 ] The present invention is directed, in general, to s 
computer processors and, more specifically, to a con- 
text controller having instruction-based time slice task 
switching capability and processor employing the con- 
text controller. 

10 

Background Of The Invention 

[0002] The processors in general-purpose computers, 
as well as those used as embedded controllers, are typ- 
ically programmed to handle a plurality of tasks concur- is 
rently. A subset of these tasks must be performed in a 
timely manner, in response to specific, exogenous 
events, while the remainder of these tasks can be per- 
formed without stringent, real-time constraints. To han- 
dle both sets of tasks using a single data path, these so 
processors require an' efficient mechanism for respond- 
ing rapidly to exogenous events, while allowing non-real 
time processing to occur whenever no exogenous 
events are being handled. 

[0003] The predominant mechanism for event ss 
response Is program interruption, which was first used 
in the mid-1950s. For the past 40 years, the vast major- 
ity of processor architectures have included a program 
interruption facility that suspends the execution of a 
"background" task, and initiates the execution of a "fore- so 
ground" task, upon occurrence of the exogenous 
event(s). Each program interruption, typically called an 
"interrupt," causes a reversible change to the execution 
state of the processor upon assertion (suitably synchro- 
nized to the processor's instruction flow) of an appropri- 35 
ate event. 

[0004] The priority interrupt, developed in the late- 
1950s, is a common enhancement to a program inter- 
ruption facility In a processor supporting priority inter- 
rupts, discrete priorities are assigned, either statically or 4o 
dynamically, to a plurality of event (inten-upt request) 
signals. Associated with each of these signals is a 
uniquely identifiable resultant state for the reversible 
change in execution state of the processor. Each occur- 
rence of a priority interrupt selects the resultant state 4s 
associated with the highest priority inten-upt request 
asserted at the time when the interrupt state change is 
initiated. 

[0005] The fundamental action when performing a 
reversible change in the program execution state of a so 
processor is to save the interrupted program's execution 
address (and implicit inter-instruction status, such as 
condition codes), and to commence interrupt process- 
ing at a program address associated with the event 
causing the interruption. This program address is gen- 55 
erally obtained from a predetermined memory location 
known as an inten-upt vector. At the end of the inten-upt 
handling routine, the saved execution address (and sta- 



tus value, if any) are restored, permitting execution of 
the interrupted program to resume at the point of inter- 
ruption. In most interrupt handling routines, it is neces- 
sary to save, and subsequently to restore, additional 
processor state to perform the operations necessary to 
respond to the interrupt. This additional state is prima- 
rily the contents of processor registers other than the 
program counter 

[0006] Saving and restoring these registers to/from a 
stack or dedicated block of memory can consume con- 
siderable amounts of time. Therefore, as integrated cir- 
cuite began reducing the cost and size of hardware 
registers in the mid-1960s, some processors were 
equipped with multiple sets of registers. Selection of a 
different set of registers, either by the interrupt support 
hardware or by the inten-upt handling software, allowed 
substantially fester interrupt response by eliminating the 
overhead of saving and restoring registers to/from main 
memory. 

[0007] The multiple register set concept reached its 
modern form on the IBM System/7, introduced in 1970. 
The System/7 had a dedicated, hardware-selected reg- 
ister set for each interrupt level, and reduced interrupt 
context switching time still further by including in each 
set a register to save the execution address (program 
counter value) when the level was preempted by an 
interrupt on a higher priority level. The result was an 
interrupt context switch time of 800ns and an interrupt 
return time of 400ns, both of which were truly excep- 
tional speeds for a 16-bit minicomputer built using 1969 
technology. The System/7 also pioneered dynamic 
interrupt assignment, where the priority level used by 
each inten-upt source was set by software, and could be 
changed during system operation. 
[0008] The ultimate generalization of this register set 
plus program counter technique was to allow events to 
initiate handling routines at their last execution address, 
rather than requiring them always to start using an inter- 
rupt vector address. For controlling I/O devices, data 
communication and network protocols, and other proc- 
esses defined in terms of communicating state 
machines, this was a major benefit, because a state 
machine could be implemented using the level's pro- 
gram counter both for instruction addressing and as the 
(implicit) state register. This not only eliminated the 
need for a separate state register, but also eliminated 
the overhead of a dispatch routine to select the appro- 
priate handling routine based on the value in the state 
register. In effect, the register set plus program counter 
architecture provides direct hardware support for the 
"task" or "execution thread" concepts commonly sup- 
ported by operating system software. 
[0009] The first machine developed with the intent to 
implement I/O control state machines using this tech- 
nique was the "Alto" experimental personal computer, 
designed in 1972 by Charles Thacker at the Xerox Palo 
Alto Research Center. Since the early-1 970's many var- 
iations of these interrupt and context switching mecha- 
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nisms have been developed for single-chip 
microcomputers and microprocessors. However, none 
of these variations have introduced a fundamentally 
new mechanism for rapid context switching In response 
to exogenous events. 

[001 0] In high-performance systems it is often possi- 
ble to dedicate (one or more) processors for I/O control 
and/or external event handling. However, if imple- 
mented with similar technology to that used in the cen- 
tral processor(s) of the system, the utilization of these 
I/O processors tends to be very low. This is due to the 
fact that, for any particular circuit technology, the logic 
devices used to implement processor data paths oper- 
ate significantly faster than the storage devices used to 
implement main memory, and both the logic and mem- 
ory devices can support higher data bandwidths than 
any of the attached peripheral devices. 
[0011] During the 1960s, the architects of high-per- 
formance systems that required multiple I/O controllers 
developed a technique to share a single data path 
among a plurality of controller functions, even though 
those functions are logically disjoint. The technique 
used a single physical data path and instruction 
decoder to process, on a round-robin basis, the instruc- 
tion streams of a plurality of logical processors. The only 
dedicated resource for each logical processor was the 
storage to hold its execution state (program counter and 
register values). The control circuitry allowed execution 
of a predetermined number of instructions (generally 1) 
for each logical processor on a sequential, cyclic basis. 
This control circuitry changed which one of the stored 
execution states was accessible to the data path 
between the instruction cycles for different logical proc- 
essors. This technique was first used by Seymour Cray 
in the early 196Gs to implement 10 I/O controllers 
(called peripheral processors or "FPUs") using a single, 
shared data path on the Control Data Corporation 
(CDC) model 6600. 

[001 2] Note that this logical processor state switching 
occurred on a strict time basis, and not in response to 
external events. Indeed, some successors to the Con- 
trol Data 6600 FPUs implemented a priority interrupt 
scheme on their logical processors. More recently this 
data path sharing technique has been applied to central 
processors, where it is called "shared resource multi- 
processing." In this case a plurality of independent 
instruction streams, from different CPU tasks or pro- 
grams, are interleaved to decrease pipeline dependen- 
cies, thereby improving resource utilization, of a 
superscalar data path. 

[001 3] Accordingly, what is needed in the art is a way 
to configure, allocate and manage contexts that has a 
more general flexibility. 

Summary Of The Invention 

[001 4] To address the above-discussed deficiencies of 
the prior art, the present invention provides a context 



controller for managing multitasking in a processor and 
a method of operating the same. In one embodiment, 
the context controller includes: (1) a time slice instruc- 
tion counter that counts a number of instructions exe- 

5 cuted with respect to a given background task and (2) a 
background task controller that cyclicly executes a con- 
text corresponding to another background task when 
the number of Instructions executed equals a dynami- 
cally-programmable time slice value. 

10 [001 5] The present invention therefore introduces the 
broad concept of providing variable instruction-based 
time slice (which may be thought of as "instruction 
slice") multitasking in which the time slice value (the 
number of instructions to be executed with respect to 

15 each background task in its allotted time slice) remains 
fully programmable during execution of the background 
tasks. In fact, "dynamically-programmable" is defined, 
for purposes of the present invention, as being program- 
mable subsequent to system initialization. "Context," for 

20 purposes of the present invention, is defined as all proc- 
essor state information (or any subset thereof, and such 
as register values) that would be of use in restoring the 
processor to a given state. 

[0016] In one embodiment of the present invention, 

2S the time slice instruction counter initially contains the 
dynamically-programmable time slice value as a time 
slice for the given background task begins, the time 
slice instruction counter decrementing as the instruc- 
tions with respect to the given background task are exe- 

30 cuted. Alternatively, the time slice instruction counter 
can be initialized to a different value and caused to 
count toward the dynamically-programmaWe time slice 
value. When the value contained in the time slice 
instruction counter reaches zero in the first case, or 

35 equals the dynamically-programmable time slice value 
in the second case, the background task controller can 
be signaled to switch to another background context. 
[0017] In one embodiment of the present invention, 
the context controller places the processor in an idle 

40 State when all of the background tasks are inactive. In 
an embodiment to be illustrated and described, the 
processor remains ready to act on the occurence of an 
event during the idle state. 

[0018] In one embodiment of the present invention, 
45 the background task controller is adapted to activate a 
context corresponding to a particular foreground task by 
vectoring to a software-selectable memory location. By 
allowing the entry point of the particular foreground task 
to vary, a state machine can be established in which the 
so initial execution address for the context activation also 
serves as the state indicator, allowing the faeground 
task to execute as a function of the event that brought 
about its execution. Of course, the same state machine 
process can take place with respect to activation of 
55 background tasks. 

[0019] In one embodiment of the present invention, 
the processor further includes a foreground task con- 
troller that activates contexts corresponding to fore- 
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ground tasks based on priority and in response to 
events, the tiackground task controller cyclicly activating 
contexts corresponding to the background tasks subject 
to activation of the contexts corresponding to the fore- 
ground tasks. An "event" is defined as a stimulus capa- 5 
ble of causing the context controller to respond by 
switching from one foreground task to another Thus, 
tasks may be divided into foreground and background 
tasks and allocated processor resources using substan- 
tially different criteria. Of course, foreground tasks may w 
also be handled on a time slice basis, perhaps in terms 
of instruction count. 

[0020] In one embodiment of the present invention, 
the dynamically-programmable time slice value is con- 
tained in a register of the processor. Alternatively, the is 
dynamically-programmable time slice value may be 
contained in a memory location external to the proces- 
sor, at the expense of processing speed. 
[0021] In one embodiment of the present invention, 
application tasks executing on the processor can pro- 20 
gram the dynamically-programmable time slice value. 
Alternatively, programming of the dynamically-program- 
mable time slice value may be limited to only the operat- 
ing system, if security of the time slice value is a priority. 
[0022] The foregoing has outlined, rather broadly, pre- 2s 
ferred and alternative features of the present invention 
so that those skilled in the art may better understand the 
detailed description of the invention that follows. Addi- 
tional features of the invention will be described herein- 
after that form the subject of the claims of the invention. 30 
Those skilled in the art should appreciate that they can 
readily use the disclosed conception and specific 
embodiment as a basis for designing or modifying other 
structures for carrying out the same purposes of the 
present invention. Those skilled in the art should also 35 
realize that such equivalent constructions do not depart 
from the spirit and scope of the invention in its broadest 
form. 

Brief Descri ption Of The Drawings 40 

[0023] For a more complete understanding of the 
present invention, reference is now made to the follow- 
ing descriptions taken in conjunction with the accompa- 
nying drawings, in which: 45 

FIGURE 1 illustrates a state transition diagram 
showing operation of one embodiment of a proces- 
sor of the present invention from the point of view of 

an individual context; so 

FIGURE 2 illustrates a diagram exemplifying possi- 
ble processing flow, preemption, and inter-context 
communication on a processor operating with five 
foreground contexts and three background con- ss 

texts; 

FIGURE 3 illustrates exemplary per-context control 



and status registers accessible to software execut- 
ing in a processor employing an embodiment of the 
present invention; 

FIGURE 4 illustrates a system diagram of a typical 
processor or I/O controller incorporating an embod- 
iment of the context controller of the present inven- 
tion; 

FIGURE 5 illustrates an interaction diagram show- 
ing an internal structure of the context controller 
illustrated in FIGURE 4; 

FIGURE 6 illustrates a process diagram of an event 
synchronization process illustrated in FIGURE 5; 

FIGURES 7A, 7B, 7C and 7D collectively illustrate 
process diagrams of the event prioritization process 
illustrated in FIGURE 5; 

FIGURE 8 illustrates a timing diagram for a context 
switoh controlled by the present invention in which a 
current context's state is stored into, and the next 
context's state is loaded from, synchronous (self- 
timed) SRAM or register files; 

FIGURE 9 illustrates a timing diagram for a context 
switch controlled by the present invention where a 
current context's state is stored into, and the next 
context's state is loaded from asynchronous SRAIM 
or register files; 

FIGURE 10 illustrates a schematic diagram of one 
embodiment of a circuit suitable for implementing 
event recording, event masking and event acknowl- 
edgment for each activation event, as well as man- 
agement of a context activity bit, including 
initialization request and wait request logic; 

FIGURE 1 1 illustrates field and bit assignments of 
machine instructions pertaining to context control 
and inter-context communication in the instruction 
set according to one embodiment of the present 
invention; 

FIGURE 12 illustrates sources of bits used to gen- 
erate control store addresses on the processor 
accoiding to one embodiment of the present inven- 
tion; 

FIGURE 13 illustrates an exemplary data structure 
diagram for initialization vectors in control store 
according to one embodiment of the present inven- 
tion; and 

FIGURE 14 illustrates a diagram setting forth target 
address generation by vector instruction used to 
prioritize and decode specific context activation bits 
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on the processor according to one embodiment of 
the present invention. 

Detailed Description 

[0024] Referring initially to FIGURE 1 , illustrated is a 
state transition diagram showing operation of one 
embodiment of a processor of the present Invention 
from the point of view of an individual context. The 
present invention provides for use of a context controller 
for managing multitasking in a processor and Introduces 
the concept of dividing taslts into foreground and back- 
ground tasks and allocating processor resources using 
substantially different criteria. 
[0025] Events (stimuli capable of causing a fore- 
ground contort switching action) are employed to deter- 
mine which foreground tasks are activated, with 
execution of active, foreground tasks based on prede- 
fined priority levels. In contrast, background tasks are 
executed cyclidy with the background tasks subject to 
activation of the contexts con-esponding to the fore- 
ground tasks. Also, background task execution may be 
based on time slice, instruction slice or any other cyclic 
allocation. Of course, foreground tasks may also be 
handled on a time slice basis, perhaps in terms of 
instruction count. 

[0026] The context controller may include a time slice 
instruction counter that counts a number of Instructions 
executed with respect to a given background task and a 
background task controller that cyclidy switches to a 
context corresponding to another background task 
when the number equals a dynamically-programmable 
time slice value. 

[0027] At any given time that the processor is operat- 
ing, each context is in one of six states, which are logi- 
cally grouped into four sets as a two rows by two 
columns (2x2) matrix. The top or foreground row 10 
contains three states: an Rf state 18, a Pf state 20 and 
a Wf state 22 (where each includes an "f" to Indicate 
foreground) used by foreground contexts. The bottom or 
background row 12 contains three states: an Rb state 
24. a Qb state 26 and a Wb state 28 (where each 
indudes a "b" to indicate background) used by back- 
ground contexts. The active column 14 contains the four 
states 18, 20. 24. 26 used by the active contexts, while 
the inactive column 16 contains the two states 22 and 
26 used by the inactive contexts, respectively. 
[0028] The foreground row 10 states may be further 
defined as Rf 18 (running, foreground), Pf 20 
(preempted, foreground) and Wf 22 (waiting, fore- 
ground). The background row 12 states may be further 
defined as Rb 24 (running, background), Qb 26 
(queued, background) and Wb 28 (waiting, back- 
ground). During each Instruction cycle, only one context 
may be "running" (executing an Instruction on the proc- 
essor), or the processor alternatively may be idle. If 
occipied, the running context is the sole context in the 
foreground running state Rf. Or if the state Rf 18 is 



unoccupied, the running context is the sole context In 
the background running state Rb 24 (If occupied). The 
execution states of contexts are generally stored in sep- 
arate register sets. 

5 [0029] Most context transitions are allowed to take 
place within either the foreground row 10 or the back- 
ground row 1 2, because Inter-row transitions are only 
needed when a context switches between foreground 
and background operating tasks which may be distln- 
10 gulshed by a software switch operation. However, this 
occurs less frequently than context activation, preemp- 
tion and waiting. Transitions from foreground to back- 
ground may only occur when the running foreground 
context Rf 18 executes a CLRFG ("dear foreground") 

15 function 34, which results in a transition from the fore- 
ground running state Rf 18 to the background queued 
state Qb 26. Because there are no relative priority dis- 
tinctions among background contexts, the position in 
the background queue given to the contert executing 

20 the CLRFG function 34 is arbitrary. 

[0030] A context executing a CLRFG function 34 is 
leaving foreground operation and advantageously relin- 
quishes control of the processor for a minimum of one 
instruction cyde (as does a context executing a WAIT 

25 function 32 or 42). If a lower priority foreground context 
is in the preempted state R 20. that lower priority fore- 
ground context runs next (via a HIGHEST PRIORITY 
transition 36). If the preempted state Pf 20 is unoccu- 
pied, a preempted context already In the background 

30 state Rb 24 runs next, unless the background state Rb 
24 is also unoccupied. In this case, the context at the 
head of the background queue in the background 
queued state Qb 26 runs next, via a TIME SLICE starts 
transition 44. In the illustrated embodiment, this occurs 

35 after a single instruction cycle with the processor idle, 
since both the foreground running state Rf 18 and the 
background running state Rb 24 are unoccupied. 
[0031 ] This embodiment of the present Invention Intro- 
duces the broad concept of providing Instruction-based 

40 time slice, which may be thought of as instruction slice, 
multitasking in which the time slice value (that Is, the 
number of instructions to be executed with respect to 
each background task in its allocated time slot) remains 
fully programmable during execution of the background 

45 tasks. Recall that dynamically programmable is defined, 
for purposes of the present invention, as being program- 
mable subsequent to system initialization. 
[0032] A transition between background and fore- 
ground normally occurs when a context in background 

so running state Rb 24 executes a SETFG ("set fore- 
ground") function 30, which results in its transition from 
the background running state Rb 24 to the faeground 
running state Rf 18. Foreground activation of a particu- 
lar context may also occur by vectoring to a soflware- 

55 selectable memory location. By allowing the entry point 
of the particular foreground task to vary, a state 
machine can be established, allowing the foreground 
task to execute as a function of the event that brought 
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about its execution. Of course, the same state macfiine 
process can take place with respect to activation of 
background tasks. 

[0033] To prevent erroneous disruption of context 
operation, the functions available in the context control- 
ler advantageously do not include a mechanism by 
wrhich a running context can change the foreground or 
background setting of any other context without also 
forcing an initialization (INIT) of that context. The INIT 
function may be executed by the running context with 
any other context as the target. An INIT function can be 
executed to the running context, but no reason exists to 
do so unless a particular embodiment attached addi- 
tional initialization side effects to the INIT function. Exe- 
cution of an INIT function leaves the target context in the 
foreground preempted slate R 20 with its program 
counter set to a predetermined initialization vector 
address, as will be discussed in greater detail below. 
[0034] Normally, the target of an INIT function resides 
in the foreground wait state Wf 22 and enters the fore- 
ground preempted state Pf 20 via a transition 40. Or, it 
may reside in the background wait state Wb 28 and 
enter the foreground preempted state Pf 20, switching 
from background to foreground via a transition 50. in 
fact, the transition 50 is also possible and equivalent, if 
the target context resides in either the background run- 
ning state Rb 24 or the background queued state Qb 26, 
but FIGURE 1 does not illustrate these two cases. 
[0035] At the end of a processor reset, all contexts are 
in the foreground wait state Wf 22, except the lowest- 
priority context, which is in the foreground running state 
Rf 18. Software executing on the context foreground 
running state Rf 18 may initiate a transition to the con- 
text foreground waiting state Wf 22 by executing a WAIT 
function 32. A foreground waiting state Wf 22 context 
transitions to the foreground preempted state Pf 20 with 
an assertion of any of that context's activation events 
that are enabled by the context's event mask or when 
the running context executes an INIT function to this 
context foreground preempted state Pf 20 via the transi- 
tion 40. 

[0036] In the illustrated embodiment, a preemption 
context switch occurs at the end of every Instruction 
cycle, with the highest priority context in the foreground 
preempted state Pf 20, if any, entering the foreground 
running state Rf 18 via the HIGHEST PRIORITY transi- 
tion 36, and the previous context in the foreground run- 
ning state Rf 18, if any, entering the foreground 
preempted state Pf 20 via a HIGHER PRIORITY 
ACTIVE transition 38. 

[0037] Software executing in the context background 
running state Rb 24 may initiate a transition to the back- 
ground waiting state Wb 28 by executing a WAIT func- 
tion 42. A context in the background waiting state Wb 28 
transitions to the background queued slate Qb 26 with 
the assertion of any of that context's activation events 
that are enabled by the context's event mask. Transi- 
tions from the background queued state Qb 26 to the 



background running state Rb 24 may only occur when 
no foreground context is running (no context in state Rf 
18). In this case, the running context if any, is in the 
background running state Rb 24, or the processor is in 
5 an idle state because no context is ready to run in either 
foreground or background. 

[0038] At the end of every instruction cycle, with the 
context running in the background state Rb 24, the time 
slice count is decremented, and on the instruction cycle 

10 when the count reaches zero, a time slice context switch 
preferably occurs. At this point, the context at the head 
of the background queue enters the background run- 
ning slate Rb 24 via the transition 44, and the context 
previously in the background running state Rb 24 enters 

IS the background queued state Qb 26 via the transition 
46. 

[0039] Generally, the background queued contexts are 
organized In a first-in, first-out (FIFO) arrangement with 
"wrap-around" occun-ing from the highest context 

20 number to the lowest context number when a previ- 
ously-running background context enters the back- 
ground queued state Qb 26. It should be noted that 
foreground preemption involves a state transition via the 
transition 36, whereas background preemption by fore- 

25 ground does not. In this case, the previously-running 
background context remains in the state Rb 24 until the 
foreground running state Rf 18 is again unoccupied and 
a background context is able to run. 
[0040] Turning now to FIGURE 2. illustrated is a dia- 

30 gram exemplifying possible processing flow, preemption 
and inter-context communication on a processor operat- 
ing with five foreground contexts and three background 
contexts. A context may be activated by the assertion of 
an event signal. 

35 [0041] Associated with each context may be zero or 
more exogenous event signals and zero or more endog- 
enous event signals. The principal difference between 
exogenous and endogenous event signals is that exog- 
enous signals are advantageously synchronized to the 

40 processor's clock before being used for context activa- 
tion decisions within the context controller. In contrast, 
endogenous signals are assumed to be generated in 
synchronism with the processor's clock and are used 
directly. 

4S [0042] Each of the context's activation events may be 
enabled and disabled under software control by setting 
and clearing bits in a context-specific event mask regis- 
ter. In addition to assertion of activation events due to 
the assertion of hardware signals from exogenous 

50 sources, such as external interfaces, or from endog- 
enous sources, such as interval timers, coprocessors or 
data transfer logic, some or all events may be asserted 
by software using signal instructions that specify a tar- 
get context number and event number within the set of 

55 events associated with the target context. Since any 
context can signal events to itself or to other contexts, 
this allows the illustrated embodiment to serve as an 
efficient mechanism for both intra-contexl and inter-con- 



text communication as well as serving as a priority inter- 
rupt controller and as a time slice controller. 
[0043] In the diagram of FIGURE 2, the vertical axis 
represents contexts, while the horizontal axis repre- 
sents context activities for each of the eight contexts s 
supported on the exemplary context controller. The hor- 
izontal axis is time, in units of instruction execution 
cycles. The wide black lines, for foreground contexts, 
and the wide cross-hatched lines, for background con- 
texts, show the running context. Vertical lines with 10 
arrows show the context switches and are labeled to 
identify the reason that a context switch occurred. The 
small perpendicular lines crossing the wide lines indi- 
cate instruction cycles. 

[0044] The numbers above each instruction cycle 75 
interval for background contexts are the values of the 
time slice instruction counter when that instruction is 
being executed. As stated earlier, the time slice instruc- 
tion counter counts the number of instructions axecuted 
with respect to a given bad^round task. Additionally, a 20 
background task controller that cyclicly activates a con^ 
text con-esponding to another bacl^round task when 
the number equals a dynamically-programmable time 
slice value may be used. The time slice instruction 
counter may contain the dynamically-programmed time 2s 
slice value for the background task and this value decre- 
ments as the instructions are executed. Alternately, the 
time slice instruction counter can be initialized to a dif- 
ferent value and caused to count toward the dynami- 
cally-programmable value. 30 
[0045] The dynamically-programmable time slice 
value is contained in a register of the processor. Alter- 
nately, the dynamically-programmable time slice value 
may be contained in a memory location external to the 
processor, at the expense of processing speed. Addi- 35 
tionally, application tasks executing on the processor 
can program the dynamically-programmable time slice 
value. Or, programming of the dynamically-programma- 
ble time slice value may be limited to only the operating 
system, if security of the time slice is a priority 40 
[0046] Continuing, the narrow dashed black lines, for 
foreground contexts, and narrow cross-hatched dashed 
lines, for background contexts, show active preempted 
contexts. Narrow dotted lines show active, queued 
background contexts. This embodiment has eight con- 45 
texts, designated context 0 (the highest priority) through 
context 7 (the lowest priority), and during this example 
is operating with a time slice instruction count of eight. 
[0047] At the time this example starts, contexts 0. 2, 4 
and 5 are all inactive foreground contexts (state \Nf). so 
Contexts 3, 6 and 7 are all background contexts with 
context 3 inactive (state Wb). context 7 queued (state 
QB) and context 6 running (state Fib). Context 1 is inac- 
tive, and has an unknown (or indeterminate) fore- 
ground/background setting. A first instruction cycle 46 55 
shown is executed by background context 6 as its time 
slice count value decrements to two. In a next instruc- 
tion cycle 47. background context 6 executes a SIGNAL 
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function to background context 3. As a result, back- 
ground context 3 becomes active entering state QB on 
the following instruction cycle. After sending the SIG- 
NAL function, background context 6 executes another 
instruction cycle 48 as its time slice count decrements 
to 0. This causes a context switch to the next highest 
context number in the active context background 
queued state QB, which is background context 7. 
[0048] Context 6 enters the QB state and context 7 
enters the Rb state at an instruction cycle 50 with a time 
slice count value of 7. After context 7 has executed 
three instructions, an exogenous event activates fore- 
ground context 4. Therefore, at the end of a next instruc- 
tion cycle 52, background context 7 is preempted by 
foreground context 4 with its time slice count value 
remaining at four during the preemption. 
[0049] Foreground context 4 executes its first instruc- 
tion while an exogenous event activates foreground 
context 2. Therefore, at the end of a next instruction 
cycle 54. foreground context 4 is preempted by fore- 
ground context 2 (at a preemption point 53) entering the 
preempted state Pf while foreground context 2 enters 
the running state Rf. After executing two instructions to 
handle its activation event, foreground context 2 exe- 
cutes a WAIT function during a third instruction cycle 
56. This WAIT function clears the activity flip-flop for 
foreground context 2. and after one more instruction 
cycle, foreground context 2 becomes inactive reverting 
to the waiting state Wf. This allows the preempted fore- 
ground context 4 to return to the running state Rf and 
execute another instruction cycle 58. Because fore- 
ground context 4 had already executed its own WAIT 
function prior to the preemption point 53, this is the final 
insb-uction executed by foreground context 4 before 
reverting to the waiting state Wf and permitting 
preempted background context 7 to resume running at 
an instruction cycle 60. After executing four more 
instructions, iDackground context 7 completes its time 
slice 62, resulting in a context switch to the next top QB 
context which is background context 3 because of a 
wrap-around of context numbers from context 7 to con- 
text 0. 

[0050] During the same insti-uction cycle 64, the back- 
ground context 3 executes the first instruction of its time 
slice 7, an exogenous event 66 activates foreground 
context 0. Therefore, at the end of this instruction cycle 
64. background context 3 is preempted by foreground 
context 0 with its time slice count value remaining at 
seven during the preemption. After executing three 
instructions to handle its activation event, foreground 
context 0 ececutes a WAIT function during a fourth 
instruction cycle 69. This WAIT function clears the activ- 
ity flip-flop for foreground context 0, and after one more 
insb-uction cycle foreground context 0 becomes inac- 
tive, reverting to the waiting state Wf. This normally 
allows the preenpted background context 3 to resume 
running, but in this example an exogenous event 68 has 
activated foreground context 5 while foreground context 
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0 was running. Note that this activation changed the 
state of foreground context 5 from the waiting state Wf 
to the preempted state Pf, showing how it is possible for 
a foreground context to enter preempted state without 
having executed any instructions since activation. 5 
[0051 ] If bacl<ground context 3 had been operating in 
foreground, the fact that foreground context 5 was in the 
preempted state Pf when foreground context 0 reverted 
to the waiting state Wf would be in-elevant, since bacl<- 
ground context 3 is higher In priority than foreground 10 
context 5. However, context 3 Is operating in bacl<- 
ground. so a WAIT function 69 executed by foreground 
context 0 results In a context switch to foreground con- 
text 5 which enters the running state Rf and begins exe- 
cuting an instruction 70 while background context 3 is 
remains preempted in state Rb. 
[0052] After executing two instructions to handle its 
activation event, foreground context 5 executes a WAIT 
function during a third instruction cycle 71. This WAIT 
function clears the activity flip-flop f or foreground con- 20 
text 5, and, after one more instruction cycle, context 5 
becomes inactive and reverts to the waiting state Wf. 
Since no other foreground contexts are active at this 
time, preempted background context 3 resumes running 
in state Rb and executes the second instruction of its 25 
time slice 72. On the next instruction cycle, background 
context 3 executes a WAIT function 73. The WAIT func- 
tion 73 clears the activity flip-flop for background context 
3, and after one more instruction cycle, background 
context 3 becomes inactive, reverting to the waiting so 
state Wb. This allows queued background context 6 to 
return to the running state Rb at an instruction cycle 74. 
Note that, even though this context switch was not initi- 
ated by the time slice count decrementing to zero, back- 
ground context 6 enters the running state Rb at the 35 
instruction cyde 74 with a full time slice count value of 
seven, rather than inheriting the partial time slice 
remaining when the background context 3 executed the 
WAIT function 73. 

[0053] As Its second instruction, the background con- 40 
text 6 executes an INIT function 76 to the foreground 
context 1 to force the foreground context 1 1nto a known 
state as may be necessary to recover from a software 
error in the code executed by context 1. This INIT func- 
tion activates context 1 as a foreground contect 45 
preempted state Pf with execution set to begin at the 
context 1 initialization vector address in control store. 
Because an active foreground context now exists, back- 
ground context 6 is preempted (at a preemption point 
77) by a context switch to context 1 after execution of so 
one more instruction. As its second instruction, context 
1 executes a CLRFG (clear foreground bit) function 78 
which causes context 1 to enter the background queued 
state Qb. Because context 1 is now on the background 
queue and there is already a context in state Rb, context 55 
1 relinquishes control of the processor (at a relinquish 
point 80) after the instaicBon cycle following the execu- 
tion of the CLRFQ function 78, thereby allowing context 
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6 In state Rb to resume executing the remainder of its 
time slice 82. 

[0054] in the remainder of this Detailed Description, 
numeric constants are in decimal unless preceded by 
"Ox" in which case they are in hexadecimal, and bit 
positions are numbered, with bit zero being the least- 
significant bit. 

[0055] Turning now to FIGURE 3, illustrated are exem- 
plary per-context control and status registers accessible 
to software executing in a processor employing an 
embodiment of the present invention. Nine control bits 
per context 84 have values that are determined by soft- 
ware, and nine status bits per context 86 have values 
that are determined by context controlled hardware, but 
whose values may be read or tested In other manners 
by software. The context controller maintains a portion 
of the state of each context. These state bits are not 
part of the execution state (which Is saved and restored 
during context swHching) because the context-specific 
state within the context controller Is required continu- 
ously for use by activation logic and also as Inputs to the 
contert switching decision logic. 
[0056] The per-context control bits 84 include a fore- 
ground (FG) bit 88 and an event mask register 90. The 
FG bit 88 is equal to one when the context is in fore- 
ground. The FG bit 88 is illustrated as being set by hard- 
ware reset execution of the INIT function with this 
context as the specified target, or execution of the 
SETFG function while this context is running. The FQ bit 
88 is illustrated as being cleared by execution of the 
CLRFG function while this context is running. The event 
mask register 90 has a bit corresponding to each of the 
activation events associated with the context. 
[0057] In the illustrated embodiment, each context is 
allotted eight activation events; the event mask register 
90 therefore contains eight bits. A given activation event 
can only activate a context when the corresponding bit 
position number which is equal to the event number has 
a value of one in the context event mask register 90. 
(however, as will be explained in greater detail below, 
the assertion of an activation event is recorded in an 
event flip-flop which remains set until execution of an 
ACKNOWLEDGE (ACK) function for the specified bit. 
Setting of the event flip-flop Is unaffected by the con- 
tents of the event mask register 90. 
[0058] The per-context status bits 86 include an ACT 
bit 92 and an event status register 94. The ACT bit 92 is 
equal to one when the context is active. The ACT bit 92 
is set by either an assertion of a non-masked activation 
event, a setting of the event mask bit for an asserted 
unacknowledged activation event or an execution of the 
INIT function with this context as the specified target. 
The ACT bit 92 is cleared by hardware reset (except for 
context 7, where the ACT bit is set by hardware reset), 
and by execution of the WAIT function while the context 
is running. The event status register 94 has a bit corre- 
sponding to each of the activation events associated 
with the context. These bits are also referred to as event 
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flip-flops in some portions of this Detailed Description. 
[0059] As stated above, in the illustrated embodiment, 
each context is allotted eight activation events, dictating 
that the event status register 94 contains at least eight 
bits. The bits corresponding to asserted events read are 
equal to one, and the bits corresponding to unasserted 
events read, including acknowledged events, are equal 
to zero. Individual event status register bits (event flip- 
flops) are set by context controller hardware upon 
detection of assertion (typically a zero-to-one transition) 
of an exogenous or endogenous event signal. The indi- 
vidual event status bits may also be set upon execution 
of a SIGNAL function specifying as a destination the 
subject event in this cont^. Individual event status reg- 
ister bits are cleared by hardware reset and by execut- 
ing an ACK function with the subject event as the 
specified target, while this context is running. In some 
cases, a particular ACK function may also be generated 
as a side-effect of executing other instructions or 
accessing particular data path (typically I/O port) regis- 
ters. 

[0060] An implementation example which illustrates 
context definition and usage for an IEEE 802.11 Media 
Access Control (MAC) controller is presented below. 
The functions of a MAC controller have been divided 
into eight contexts, designated 0 to 7, with 0 being the 
highest priority. Contexts 0 to 5 are preferably fore- 
ground and 6 and 7 are preferably background. Each 
context has eight activation events and each of the acti- 
vation events generally apply the following defaults: 

A. an event may not be asserted using the SIGNAL 
function (unless the event is reserved for such 
purpose); 

B. an event is cleared using the ACK function; 

C. timer terminal count events occur when the cor- 
responding timer decrements to zero; 

D. timer terminal count events are cleared by writ- 
ing to the corresponding timer's control register 
with ClearTC(bit2) equal to one. not the ACK 
function; 

F. "assertion" of an external event signal is defined 
as a 0 to 1 transition; 

G. "negation" of an external event signal means a 1 

to 0 transition; and 

H. control bit names are chosen to be meaningful 
when the bit is equal to one. 



CONTEXT 0 - Debug support (and high-priority, real- 
time events): 

Activation Events: 

5 

[0062] 

0) hardware breakpoint (BKPTin); 
10 1 ) software breakpoint (signal 0,1); 

2) GP serial shift complete or UART transmitter 
done (GPDN/UTXDN): 

IS 3) interval timer A terminal count (INTATC); 

4) UART receiver done (URXDN); 

5) interval timer B count (INTBTC); 

20 

6) host (computer system) attention (HATN); and 

7) coprocessor attention (CPATN). 

2S Context 1 - Lower MAC (LMAC) Exception Handling 
Activation Events: 
[0063] 

30 

0) modem data interface attention (MDIATN); 

1) physical layer data not available(IPDA): 

35 2) IFS (inter-frame space) timer terminal count 
(IFSTC); 

3) inter-context communication from MMAC to 
LMAC; 

40 

4) physical layer transmitter not ready (ITXR); 

5) beacon/dwell timer comparator equal (BCNTC); 

45 6) modem data interface programmable bit bound- 
ary (MDIBIT); and 

7) modem management interface transfer complete 
(MMIDN). 

50 

Context 2 - Lower MAC (LMAC) Data Transfere: 
Activation Events: 



[0061] The exemplary contexts and their correspond- ss [0064] 
ing activation events are described below. 

0) modem data intertece attention (MDIATN); 
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1) interval timer B terminal count (INTBTC); 

2) IFS (inter-frame space) timer terminal count 
(IFSTC); 

5 

3) inter-context communication from MMAC to 
LMAC (signal 2,3); 

4) TSFT (the synchronization function timer) wrap- 
around (TSFWRP); 10 

5) NAV (network allocation vector) timer terminal 
count (INTCTC); 

6) physical layer medium busy (MBUSY); and is 

7) physical layer medium not busy (IMBUSY). 
Context 3 ■ Host Interface Siwort: 

20 

Activation Events: 
[0065] 

0) buffer access path 0 offset resolution 25 
(BUFATNO); 

1) buffer access path l offset resolution 
(BUFATN1); 

30 

2) inter-context communication for status reporting 
to host (signal 3,2); 

3) buffer access path 0 block boundary crossing 
(BLKATNO); as 

4) buffer access path 1 block boundary crossing 
(BLKATN1); 

5) inter-context communication for status reporting 40 
to host (signal 3,5); 

6) host interface register attention (HATN); and 

7) inter-context communication from background 4S 
(signal 3.7). 

Content 4 - Middle MAC (MMAC) Medium Access and 

Timing: 

so 

Activation Events: 
[0066] 

0) inter-context communication from LMAC or 55 
HMAG (signal 4,0); 

1) previously-busy medium becomes available 
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(MAVL); 

2) IFS/slot timer terminal count (IFSTC); 

3) interval timer A terminal count (INTATC); 

4) beacon/dwell timer comparator (BCNTC); 

5) modem data interface attention (MDIATN); 

6) software flags 3-0 (shared with context 7. event 

7) ; and 

7) modem management interiiace transfer cortplete 
(MMIDI). 

Context 5 - WEP (wired equivalent privacy) Decryption 
Support: 

Activation Events: 
[0067] 

0) inter-context communication for status reporting 
(signal 5,0); 

1) decryption keystream values ready (DECFJYPT); 

2) GP serial shift complete or UART transmitter 
done (GPDN/UTXDN); 

3) inter-context communication (signal 5,3); 

4) UART receiver transfer done (URXDN); 

5) inter-context communication (sijgnal 5,5); 

6) interval timer D terminal count (INTDTC); and 

7) modem management interface transfer complete 
(MMIDN). 

Context 6 - Additional Access Point Functions: 

Activation Events: 

[0068] 

0) software flags 11-8; 

1) software flags 15-12; 

2) GP serial shift conplete or UART transmitter 

done (GPDN/UTXDN); 

3) interval timer A terminal count (INTATC); 

4) software flags 7-4; 



10 



19 



EP0 942 365 A2 



20 



5) interval timer B terminal count (INTBTC); 

6) interval timer D terminal count (INTDTC); and 

7) coprocessor attention (CPATN). 

Context 7 - Upper MAC (UMAC) and Miscellaneous 
Support: 

Activation Events: 
[0069] 

0) software flags 19-16; 

1) software flags 23-20; 

2) software flags 27-24; 

3) interval timer A terminal count (INTATC); 

4) beacon/dwell timer comparator (BCNTC); 

5) interval timer B terminal count (INTBTC); 

6) interval timer D terminal count (INTDTC); and 

7) software flags 3-0 (shared with context 4, event 
6). 

[0070] Turning now to FIGURE 4, illustrated is a sys- 
tem diagram of a typical processor or I/O controller 
incorporating an embodiment of the context controller of 
the present invention. This diagram (as well as those 
illustrated in FIGURES 5. 6 and 7) is presented using 
the well-known graphical syntax of the Specification and 
Description Language (SDL) as standardized by the 
International Telecommunication Union in ITU-T Rec- 
ommendation Z.I 00 (03/93). 

[0071] The system behavior is presented using this 
formal description language because more precision 
and broader general applicability are achievable. For 
example, a schematic fragment could be used to high- 
light implementation characteristics of the illustrated 
en*odiment. However, since this context controller is 
applicable to almost any type of processor, the sche- 
matic for a particular processor is likely to omit aspects 
of the control sequences which are inplicit for that proc- 
essor but may be relevant to another processor using a 
different architecture. Also, a conventional state dia- 
gram is a more informal notation having a similar objec- 
tive to the SDL process diagram. SDL has a rigorously 
defined graphical syntax, however, achieving much less 
ambiguity. Indeed, It has been found that many "tx)und- 
ary conditions" in the behavior of this controller are not 
adequately explained by conventional state diagrams. 
Examples of these boundary conditions, all of which are 
covered by the SDL description herein, include: (1) 



What happens if a context is preempted between exe- 
cution of a WAIT function and execution of the instruc- 
tion following the WAIT function? (2) What happens if a 
context executes the ACK function for the event which 

5 caused its activation during the instruction after execut- 
ing a WAIT function? and (3)lf a background context's 
time slice ends on the same instruction cycle as it exe- 
cutes a SETFG function, does that context continue 
running in foreground, or does the next context in state 

w Qb execute one instruction before being preempted by 
the new foreground context? Also, SDL is able to 
describe the behavior of the context controller with more 
precision and less ambiguity than is possible using Eng- 
lish prose. TTierefore, the SDL descriptions presented in 

IS the following paragraphs are intended to serve as both 
a general and a detailed guide to the structure and 
intended purpose of the significant features of several 
embodiments of this invention. 
[0072] An SDL system diagram 1 00 shows the rela- 
te vant top-level functional blocks of the processor used in 
the illustrated embodiment. Text symbols 102 and 104 
contain the definitions of the system-specific extensions 
to SDL's predefined data types, declarations of the 
remote variables used for implicit inter-block communi- 

2S cation via the export/import mechanism and declara- 
tions of the names and parameter types of the signals 
used for explicit inter-block communication. The system 
diagram 100 shown comprises five functional blocks: a 
clock generator 106, a sequencer 108. an insti^ction 

30 decoder 1 12, a data path and interface resources man- 
ager 114 and a context controller 110. 
[0073] The clock generator 106 accepts an input 
clock, or timebase reference (e.g., crystal-controlled 
signal) from which is generated a clock, via Clocksin 

35 channel 122 and a hardware reset signal via Resetin 
channel 120. The clock generator 106 generates the 
cycle clocks used by all other blocks. These cycle clocks 
subdivide the instruction cycle into four, substantially 
equal portions. This is done using a pair of square 

40 waves in quadrature, resulting in four clock edges at 
which to initiate various actions. Actual dock waveforms 
are illustrated in FIGURES 8 and 9, with a master clock 
MCLK signal 504 delimiting the instruction cycle bound- 
aries and a quadrature clock QCLK signal 506 providing 

45 additional clock edges within each instruction cycle. The 
four edges, in sequential order, are: a rising edge of the 
MCLK signal 504, designated Mr 517. which marks the 
end of one instruction cycle and the beginning of the 
next instruction cycle, a rising edge of the QCLK signal 

so 506, designated Qr 51 8. which occurs 25% of the way 
through each instruction cyde, a falling edge of the 
MCLK signal 504, designated Mf 519, which occurs 
50% of the way through each instruction cycle, and a 
falling edge of the QCLK signal 506, designated Qf 520, 

55 which occurs 75% of the way through each instruction 
cycle. 

[0074] In the SDL model, the clock generator 106 
sends appropriate Mr 51 7, Qr 51 8, Mf 51 9 ot Qf 520 sig- 
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nals, as well as a reset signal, to all other functional 
blocks. The clock generator 106 operates while the 
processor is either running or idle, but can shut down 
most of its circuitry, including the generation of the 
MCLK signal 504 and the QCLK signal 506, during a 5 
very-low-power sleep mode, which Is entered when the 
clock generator 106 receives a sleep signal from the 
context controller 110 via channel ClkCct1 140. 
[0075] In many implementations, it is not possible to 
execute an instruction during every clock cycle. As a 10 
result, the instruction decoder 112, sequencer 108 and 
context controller 110 only perform their functions dur- 
ing the cycle when the instruction is actually being exe- 
cuted, as identified by the remote Boolean variable "ien" 
being true (see text symbols 1 02). is 
[0076] The sequencer 108 generates instruction 
addresses and initiates instruction fetch cycles via a 
ToCS channel 116. These addresses connect to a con- 
trol store array 117 logically ©eternal to the processor 
100. Note that, depending on the implementation tech- 20 
nology and desired performance level, the control store 
array 117 and an associated data store 127 may be 
physically separate, fully co-located in a single memory 
device, or any hybrid thereof. The sequencer 108 
receives context switching signals CsLoad (to retrieve 25 
saved context state information). CsStore (to save con- 
text state information) and InitSeq (to set a context exe- 
cution address to the appropriate initialization vector) 
from the context controller 1 10 via CctlSeq channel 141 . 
[0077] The instruction decoder 112 receives the 30 
instruction words fetched under control of the 
sequencer 108 via a FromCS channel 118. Decoded 
instructions are sent as signals, with the instruction field 
values as parameters, to all other blocks as appropriate. 
The instructions requiring processing in the context con- 35 
troller 110 are sent via an InstCctI channel 142. 
[0078] The data path and interface resources man- 
ager 114 represents the remainder of the processor, 
including the ALU. programmer-visible registers and so 
forth. All of the I/O device, host computer (if any) and 40 
local data memory interfaces (channels126. 128. 130. 
1 32) connect to this functional block. The data path and 
interface resources manager 1 1 4 sends event signals to 
the context controller 110 and receives an AckEv signal 
(which indicates that software has executed an ACK 4S 
function to acknowledge a specific prior Event). CsLoad 
and CsStore signals (to restore and to save context 
state information), and SetCy and ClearCy signals (to 
set and clear a carry flag for use after hardware reset 
and INIT functions) from the context controller 1 1 0 via a so 
CctllDP channel 143. This functional block also exports 
the values of ien (equal to true if the current clock cycle 
is an instruction execution cycle) and slice (the last 
value specified by software for the initial instruction 
count for each background time slice). ss 
[0079] The context controller 110 advantageously 
accepts exogenous event signals via an Eventsin chan- 
nel 124, and communicates with other functional btacks 



as mentioned above. This functional block also exports 
the values of Boolean variables asleep (equal to true 
when in sleep mode), CSW (equal to true during the 
second half of context switch cycles) and idle (equal to 
true when there are no active contexts), GtxNum (con- 
text number), variables context (the running context's 
number), and nctx (the number of the context to which 
execution is being switched). And, this functional block 
also exports BitString variables events (the current con- 
text's event status register) and mask (the current con- 
text's event mask register value). 
[0080] Turning now to FIGURE 5, illustrated is an SDL 
process interaction diagram showing an internal struc- 
ture of the context controller 1 10 illustrated in FIGURE 
4. The internal structures of the other top-level blocks 
are not presented herein because they are not part of 
the present invention and are not required to under- 
stand the behavior of the context controller 1 10. 
[0081] Two processes are illustrated as being con- 
tained in frie context controller block 1 10. An event syn- 
chronizer 150 accepts exogenous event signals from an 
AsyncEvents signal route 158 and synchronizes them 
with the master clock rising edge Mr 517, which is pro- 
vided by the clock generator 106 via a ClkSyn signal 
route 156. These events are sent on, via a SyncEvents 
signal route 166, as event signals, just as with the 
(inherently synchronized) event signals from endog- 
enous sources on a PrlDP signal route 164. 
[0082] The fundamental context control state machine 
operates in an event prioritizer process 152 in this 
embodiment. The event prioritizer 152 receives input 
signals from the clock generator 106 via a ClkPri signal 
route 154, event signals from the event synchronizer 
150 via a SyncEvents signal route 166 and data path 
CctlDP functions 143 via a PrlDP signal route 164. 
Additionally, decode signals for various instructions rel- 
evant to context control and inter-context communica- 
tion from an instruction decoder over the InstCctI 
channel 142 via an InstPri signal route 162 are 
received. 

[0083] Turning now to FIGURE 6, illustrated is a proc- 
ess diagram of the event syndironization process illus- 
trated in FIGURE 5 which depicts the operation of the 
event synchronizer 1 50. This process ensures that each 
incoming ExtEvent signal 208 is saved until the occur- 
rence of a master clock rising edge Mr 206. at which 
time all saved ExtEvent signals 214 are received and 
immediately passed to the event prioritizer 152 as Event 
signals 218. 

[0084] Turning now to FIGURES 7A, 7B, 7C and 7D, 
collectively illustrated are process diagrams of the event 
prioritization process shown in FIGURE 5 defining the 
state transitions of the event prioritizer 152 process. 
This process implements the event driven and time- 
sliced context switching functions for this embodiment 
of the present invention. 

[0085] FIGURE 7A defines the startup and reset 
sequences. In 'all states" syrrbcA 272. a reset signal 
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274 takes precedence over all other input signals and 
causes the process input queue (symbols 276-280) to 
be flushed before joining a startup initialization (symbol 
282) starting at a start symbol 254. A sequence (sym- 
bols 256-270) initializes all relevant variables, clearing 5 
event masks, event status registers and wait flip-flops, 
setting all contexts to foreground, and clearing all ACT 
flip-flops, except for that of context 7. whicli is forced 

[0086] FIGURE 7B defines operation during the sec- 10 
ond half of each cycle, an Mf to Mr period, (a period 
from a master clock falling edge Mf to its next rising 
edge Mr), as well as the events immediately following 
the receipt of a master clock rising edge Mr 292. Run- 
ning and idle states 284 ijoth have the same transitions, is 
since an instruction is executed during the cycle follow- 
ing a WAIT function, and because events may occur 
and need to be processed during any cycle, including 
times when the processor is idle. During the Mf-to-Mr 
period, ail instruction decode signals except an ACK 20 
(Acklnst). a WAIT or a SLEEP function 300 are proc- 
essed immediately These three signals are saved for 
processing after the master clock rising edge Mr 292 
because they must be handled after all Event signals 
288 have been processed. The instructions handled ss 
ahead of the master clock rising edge Mr 292 (that is, 
the signals 286, 290, 294, 296, 209) may alter informa- 
tion that has to be saved at the master clock rising edge 
Mr 292 if a context switch occurs. 
[0087] After the master clock rising edge Mr 292, on 30 
cycles when ien is equal to true (one)(293), the values 
of CSW (context switch in progress flag), CTX (current 
context number), NCTX (next context number), and the 
event mask and event status registers are updated 
(symbols 320, 321, respectively). The processor may 35 
enter a Sleeping state (symbol 338) during which the 
processor clocks stop, and only a low-frequency sleep 
timer operates until either a sleep timeout (a Wake sig- 
nal, in symbol 340) or a hardware reset occurs. If not 
asleep, a time slice instruction count is decremented 40 
(symbol 330) if a background context is running (sym- 
bols 326. 328). If the slice count decrements to zero 
(symbol 332). a time slice context switch is initiated by 
advancing the round-robin curBg (cunent background 
context) pointer by one, modulo the number of contexts 45 
(symbol 334), and the time slice instruction count is 
reset (symbol 335) to its programmed value. Then a pri- 
oritize state 336 is entered to handle an Mr-to Qr period 
(a period from a master dock rising edge Mr to the next 
quadrature clock rising edge Qr). so 
[0088] FIGURE 7C defines operation during the first 
quarter of each cycle (the Mr-to Qr period). This is the 
time when the events sampled at the master clock rising 
edge Mr 292 are masked and the ACT flip-flops are 
updated in preparation for making a context switching 55 
decision after a quadrature clock rising edge Qr 380. An 
ACK (Acklnst) signal 352. a WAIT signal 360 and a 
SLEEP signal 366 are handed prior to the quadrature 



clock rising edge Qr 380. and a masking and ACT 
updating sequence (symbols 386-392) occurs following 
the quadrature clock rising edge Qr 380. 
[0089] The updating of ACT bits is depicted as an iter- 
ative process (symbols 388-392) for clarity regarding 
the operation being performed. This operation is typi- 
cally performed for all contexts in parallel. A subtle, but 
very inrportant action in FIGURE 7C is the handling of a 
WAIT function 360, where the occurrence of the WAIT 
function 360 is recorded at the index of the previous 
(prev) context (symbol 362) (which is the context that 
was running prior to the master clock rising edge Mr 292 
when the WAIT function 360was decoded). Then the 
clearing of the ACT flip-flop (symbols 382-384) is done 
at the index of the current (ctx) context. The values of 
prev and ctx will be equal both before and after the 
quadrature dock rising edge Qr 380 in all cases except 
when a context switch occuned immediately preceding 
the master clock rising edge Mr 292. This means that a 
context executing a WAIT function on the last cyde 
before a context switch remains active, but with its Wait 
flip-flop (bit in the waited bit string) being equal to one 
until that context is again able to run and execute the 
instruction following the WAIT function. Another inter- 
esting action in FIGURE 7C is the sending of an AckEv 
signal 356 to the Data Path when an ACK function 352 
is processed. This is done to permit side-effects in the 
device or host interface logic to be performed when a 
specific event is acknowledged. 
[0090] FIGURE 7D defines operation during the sec- 
ond quarter of each cycle, a Qr-to Mf period, (a period 
from a quadrature clock rising edge Qr to the next mas- 
ter clock falling edge Mf). This is the time period when 
events are prioritized and the context switching deci- 
sions are made. The first set of actions (symbols 422- 
428) searches for a possible preemption. The search is 
depicted as an iterative process for clarity regarding the 
operation being performed. This operation is typically 
performed for all contexts in parallel. If the running con- 
text is in foreground, the search is over the range 0:ctx, 
whereas if the running context is in background the 
search is over the range 0:7 because all foreground 
contacts have priority over any background context 
(symbol 423). The priority encoding (symbd 424) is 
implicit in the ascending context number 424 (descend- 
ing prfority) sequence. If an active, foreground context is 
found, its number is recorded in nctx (symbol 452). 0th- 
enwise. a search (blocks 430-434) is conducted for an 
active background context starting at the indicated cur- 
rent baclground context and continuing to higher con- 
text numbers (modulo 8). 

[0091 ] If a time slice (the symbol 334 of FIGURE 7B) 
ends at the master dock rising edge Mr 292 of this 
cycle, the indicated curBg will already have been incre- 
mented, meaning the search will start from the context 
after the one that is currently running and will only re- 
select the same context if no other contexts are in the 
queued state Qb. In the case of a preempted context in 
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the bacl^rouncl running state Rb that can now be 
resumed, this test (symbol 430) will exit immediately to 
a set new context number (nctx) 450. If either a fore- 
ground (symbol 452) or a background (symbol 450) 
search finds a context to run, the nrtx is compared with 
the current context number (ctx) (symbol 454) to deter- 
mine whether a context switch is needed. If a context 
switch is not needed, no further context control activities 
occur during this cycle and the controller returns to a 
running state 458. 

[0092] If a context switch is required, the controller 
enters Start -CSW state 456 saving the input signals 
462 until a master dock falling edge Mf occurs (symbol 
460). Then CSW (symbols 474-476) is asserted, and 
the loading of the saved state of the next context (sym- 
bol 478) is initiated while saving the cun-enl context 
state (symbol 480) is requested. The reason loading is 
requested before storing is explained below more fully 
in conjunction with FIGURES 8 and 9. 
[0093] If there are no active contexts, the controller 
saves all input signals (symbol 440) until the master 
clock falling edge Mf occurs (symbol 438), then indi- 
cates an Idle state 442 and requests saving the current 
context state 446 before actually entering an Idle state 
448. The context state is saved because there is no 
guarantee that the same context will be the first context 
to run at the end of the idle period. In effect, the transi- 
tion to and from the Idle state 448 is a split context 
switch, with saving during the transition to Idle (symbols 
442-446), and loading during the transition from idle 
(symbols 466-470). During the idle state, the clocks 
continue to run and events continue to be sampled, but 
instructions are neither fetched nor executed. The proc- 
essor remains ready to act, however, on the occurrence 
of an event during the idle state. 
[0094] If the processor is implemented using comple- 
mentary metal oxide semiconductor (CMOS), or 
another process technology where power consumption 
is very low or essentially zero when the circuit elements 
are not being clocked or changing level, the Idle state 
448 provides an inherent power saving mode for most of 
the proc^sor. including sequencer, instruction decoder 
and data path. If a still lower power operating mode is 
desired, the SLEEP function 366 On FIGURE 7C) can 
stop the high-speed clocks, along with suspending 
event monitoring, leaving only a low-frequency sleep 
timer in operation. 

[0095] Turning now to FIGURE 8, illustrated is a timing 
diagram for a context switch controlled by the present 
invention in which a current context's state is stored into, 
and the next context's state is loaded from, synchro- 
nous (self-timed) SRAM or register files. The timing dia- 
grams depicted (in both FIGURES 8 and 9) identify the 
differences required to use each of two different types of 
memory technology for storing the execution states of 
non-running contexts. Each of these timing sequences 
has the beneficial advantage that the context switch 
operation does not require extra cycles to save and 



restore the context execution state, but rather performs 
this function in parallel with execution of the last instruc- 
tion of the context being switched. To employ this tech- 
nique, a processor data path should include dedicated 

5 register files or static RAM (SRAM) arrays for each reg- 
ister in the execution state. The illustrated embodiment 
of the invention may be used in conjunction with proces- 
sor data paths that do not provide such storage. How- 
ever, more overhead is associated with context 

to switching on such processors, due to possible extra 
cycles and an execution of additional instructions to 
save and restore context execution states. 
[0096] The simpler timing and control signal sequenc- 
ing, shown in FIGURE 8. is achieved when the save 

IS arrays are implemented using synchronous static (self- 
timed) RAM (SRAM). This is also the timing that results 
from a direct implementation based on the SDL process 
defined in FIGURE 7. Although programmer-visible 
behavior is identical, greater complexity is required to 

20 use asynchronous static RAM for the save an^ys (as 
will be discussed in conjunction with FIGURE 9). An 
approach using synchronous SRAM permits shorter 
cycle times and lower power consumption due to a 
reduced number of signal transitions and an elimination 

25 of control signal duty cycles shorter than 50% of the 
instruction cycle time, assuming identical performance 
of the synchronous SRAM and asynchronous SRAM 
devices. 

[0097] The synchronous SRAM captures the write 

30 address and data at a leading edge of each write enable 
pulse, and completes the write operation using inter- 
nally generated control signals, without need for stable 
input signals (other than power) during the remainder of 
the write cyde. Cell-based, semi-custom integrated cir- 

35 cuits employing synchronous SRAM that use register 
file cells with both a read port and a write port having 
independent addresses are readily available. The con- 
trol signal timing for a context switch becomes relatively 
simple when using these synchronous SRAM cells to 

40 implement the save arrays, as shown in FIGURE 8. 
[0098] During each instruction execute cycle 500, 502 
a context controller 514 sanples activation event sig- 
nals at a master clock rising edge Mr 517 allowing the 
first quarter of the cycle for settling and gating of the 

4S synchronized signals (time interval 532). At a quadra- 
ture clock rising edge Qr 518, all ACT flip-flops are 
updated and the priority encoding and comparison 
operations determine the need for a context switch, 
selecting a next context if required (time interval 533). In 

so parallel with these context controller activities, a proces- 
sor (time interval 51 8) has been executing an instruction 
initiated at the master clock rising edge Mr 517, without 
regard for whether a context switch may be necessary 
during ttiis instruction execution cycle. If a processor 

55 data path has combinatorial paths from internal register 
sources that are expected to be stable throughout the 
execution cycle, values on these paths must be latched 
at a master clock failing edge Mf 519 to permit readout 



14 



27 



EP0 942 365 A2 



of a saved state of a next context to begin (time interval 
540). Alternately, if a processor designer prefers to add 
overhead cycles for reading a saved context state, this 
latching is not required. But, in most cases, one or more 
cycles are inserted and a net effect will be a slowdown 5 
of processing and real-time response if these latches 
are eliminated, resulting in a period when instructions 
cannot be executed between a last instruction cycle of 
an old context and a first instruction cycle of a new con- 
text. ,0 
[0099] At the master clock falling edge Mf 519, the 
context controller can determine whether a context 
switch is required (time interval 534). and assert an 
CSW signal 522 if so. The target state to be restored is 
indicated by placing a context number of a next context is 
on a NCTX[2:0] signal group 530. This starts a "saved 
State" readout of a next context (time interval 540) using 
a NCTX[2:0] signal group 512 to address the save 
arrays in parallel with a completion of the last instruction 
of the current context (whose context number remains zo 
on a CTX[2:0] signal group 524). 
[0100] At the end of this context switch cyde desig- 
nated by the master clock rising edge Mr 517 (separat- 
ing cycle 500 from cycle 502), an execution slate of a 
current context, including an outcome generated during 2s 
this execution cycle 500. is stored (time interval 542) 
using a CTX [2:0] signal group 510 to address the save 
arrays. The save array write operation (a time 542) is ini- 
tiated by the master clock rising edge Mr 517 when a 
CSW signal 508 is asserted (time interval 522). Due to 30 
the advantageous characteristics of writing to synchro- 
nous SRAM, a first instruction of the next context can 
commence execution immediately (time interval 536), 
since neither the address nor data being written to the 
save array has to be held after the master clock rising 35 
edge Mr 517 occurs, which ends cycle 500. For proper 
execution, the synchronous SRAM cycle time, including 
write recovery, may not exceed 50% of an instruction 
cycle period. The same master clock rising edge Mr 51 7 
transition that initiates an SRAM write may also be 40 
advantageously employed to complete a context switch 
with a CSW signal 508 negated and a CTX [2:0] signal 
group 51 0 updated to a new context number 526. 
[0101 ] Turning now to FIGURE 9. illustrated is a timing 
diagram for a context switch controlled by the present 45 
invention in which the current context's state is stored 
into, and the next context's state is loaded from, asyn- 
chronous SRAM or register files. Conventional, or asyn- 
chronous, SRAM requires that a write address and data 
be stable throughout a relevant portion of a write cycle, so 
This necessitates a setup time prior to a trailing edge of 
a write enable pulse and sometimes requires a short 
hold time following this trailing edge. Many semi-custom 
integrated circuit technologies can supply RAM arrays 
or register files using asynchronous SRAM that pro- ss 
vides a single address and data port which may be used 
for either reading or writing. Separate SRAM and regis- 
ter file chips that operate in this manner are also widely 



available. 

[0102] To use this type of conventional, single-port 
SRAM to implement the save arrays, control signal tim- 
ing for a context switch becomes somewhat more com- 
plicated, as shown in FIGURE 9. General timing is the 
same as in FIGURE 8, and similar elements are Identi- 
fied using the same reference numbers. A primary dif- 
ference is the generation of the NCTX[2:0] signal group 
512, in operations by a context controller 514, and a 
data path 516 during and immediately after an assertion 
of a CSW signal 548 (as detailed in times 522, 528, 530, 
534, 535, 537, 540, 541, 543 of FIGURE 9). It is neces- 
sary to use asynchronous SRAM with a cycle time that 
does not exceed 25% of the instruction cyde period 
including write recovery in order to avoid insertion of 
overhead cycles, assuming no instructions are exe- 
cuted while saving and restoring a context state. This 
speed requirement is twice as fast as that needed to 
achieve the same processor cycle rate when using syn- 
chronous SRAM. The context switch activities are iden- 
tical during the first half of the context switch cyde (time 
intervals 532, 533, 538). At a master clock felling edge 
Mf 519 of the context switch cyde, a CSW signal 508 is 
asserted (time interval 522) and a NCTX[2:0] signal 
group 512 is set to the next context number (time inter- 
val 534). Address and data information must be stable 
while writing the results of the last instruction executed 
by the current context into the save arrays. Therefore, 
only a period from the master clock falling edge Mf 519 
to the next quadrature dock falling edge Qf 520 is avail- 
able for readout of the saved state for the next context 
(time interval 540). This outcome is then preferably 
latched and held during a period from the quadrature 
clock falling edge Qf 520 to the next master clock rising 
edge Mr 517. Then, these latched values are advanta- 
geously transferred to the processor's working registers 
(time interval 543). At the quadrature clock falling edge 
Qf 520, the value of the NCTX[2:0] signal group 512 
switches back to the current context number (time inter- 
val 535), allownng the current context state including 
results of this instruction (cyde 500) to be written to the 
save arrays (time interval 541). At the master clock ris- 
ing edge Mr 517, the NCTX[2:0] signal group 512 
switches back to the next context number (time interval 
530) and execution of a first instruction of the next con- 
text begins (time interval 537). 
[0103] Unlike the synchronous SRAM implementa- 
tion, the write operation is conpleted at the master 
dock rising edge Mr 517. Use of the asynchronous 
SRAM requires that the data path results be stable rela- 
tively early to allow writing to the save arrays during the 
interval from the quadrature clock falling edge Qf 520 to 
the master dock rising edge Mr 51 7. Whereas with syn- 
chronous SRAM, the data path results are not needed 
until just prior to the master clock rising edge Mr 517, 
which facilitates shorter instrudion cycles and therefore 
faster processing. 

[0104] Turning now to FIGURE 10. illustrated is a 
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schematic diagram of one embodiment of a circuit suit- 
able for implementing event recording, event masking 
and event acknowledgment for each activation event, as 
well as management of a context activity bit, including 
initialization request and wait request logic where the 5 
details of event recording, masking and acknowledg- 
ment within the context controller may better be under- 
stood. 

[0105] A generalized schematic fragment of a "slice" 
of a context controller event logic is presented for a sin- 10 
gle event including an ACT bit and WAIT function logic 
of the context associated with that event In this dia- 
gram, all logic signals are considered to be asserted in 
the "high" true (logical one) state. This schematic frag- 
ment is illustrative of an embodiment of the event logic is 
and is not meant to be a limitation on practice of the 
present invention. 

[0106] An exogenous event signal 550 may be 
asserted with either polarity, so a programmable inver- 
sion function 560. under control of a software signal 551 20 
may be provided to establish a high-true signal for inter- 
nal use. Because this exogenous signal has an undeter- 
mined phase relationship with the internal clocks, a 
synchronizer 562 that synchronizes the input signal with 
a master clock rising edge Mr 517 prior to its internal 2s 
use is employed. A plurality of sources may be used to 
set an event flip-flop 570 including a leading edge of a 
synchronized external signal 564, a leading edge of an 
internal source 566, or a software SIGNAL function 552 
which designates this context and event. These event 30 
sources are combined by an OR gate 568 whose output 
enables an event flip-flop 570 to be set at the master 
clock rising edge Mr 517. 

[01 07] Because the event flip-flop D-input 570 is hard- 
wired true (to a logical one as shown), negation of an 3S 
event signal after setting the event flip-flop 570 does not 
rescind the event. The event flip-flop output 570 may be 
read by software as a bit in the event status register 94 
and as a testable condition in an events condition signal 
group 596 if the processor provides instructions such as 40 
the SKPn of the illustrated embodiment (as described 
below). The event flip-flop 570 can be cleared either by 
a hardware reset 555 or an AND gate 572 output, 
whose ANDed inputs incorporate the execution of an 
ACK (acknowledge) function 554 for this event number 4S 
while this context is running (a signal 556). applied 
through an OR gate 574. 

[0108] An appropriate bit for this context event from 
the context's event mask register 94, event mask bit 558 
is ANDed in an AND gate 580 with an event flip-flop out- so 
put 570 and applied to the input of an ACT flip-flop 590 
through an OR gate 584. The output of this AND gate 
580 is also used when performing priority encoding of 
the context events for the VECTOR function, as is 
described in greater detail below. A masked event sig- ss 
nal from the AND gate 580 is ORed in the OR gate 584 
with the masked event signals from all other events 
associated with this context including a signal from the 



output gate of the wait logic through an AND gate 582. 
[0109] A logical true output condition of the OR gate 
584 enables the ACT flip-flop 590, allowing the ACT flip- 
flop 590 to be set to the output value of a NOT inverter 
586 at the quadrature clock rising edge Qr 518. By 
using the output of the AND gate 582 and an inversion 
of the same signal through the NOT inverter 586, the 
Act flip-flop 590 D-input may be enabled. The ACT flip- 
f top 590 is set at the quadrature clock rising edge Qr 
518 if one or more activation events are asserted, and 
no WAIT function was executed during the preceding 
instruction cycle. The ACT flip-flop 590 may also be set 
directly by execution of an INIT function 588 to this con- 
text, and cleared directly by a hardware reset signal 
555. The ACT flip-flop output 590 Is also used by the 
context priority logic and is Inverted by a NOT inverter 
592 to clear a WAIT flip-flop 578. The ACT flip-flop 590 
is cleared through the NOT inverter 586 if a WAIT func- 
tion was executed during the preceding instnjction cycle 
whether or not any activation events are asserted. 
[01 1 0] The WAIT flip-flop 578 is needed because a 
context may be preempted between executing a WAIT 
function and executing an instruction which follows the 
WAIT function. (An example of this occunence is shown 
at 53, 54 and 58 of FIGURE 2). When a WAIT function 
557 is decoded by an AND gate 576 while this context is 
running (a signal 556), the WAIT flip-flop 578 is enabled 
to set at the master clock rising edge Mr 517. Because 
a context must be active to execute a WAIT function, 
this action records the occurrence of the WAIT function 
since the output of the ACT flip-flop 590 being in the true 
state negates the clear input of the WAIT flip-flop 578 
through the NOT inverter 592. 
[0111] At the next quadrature clock rising edge Qr 
518, in which this context is a running state (the signal 
556), the ACT flip-flop 590 is cleared due to assertion of 
the AND gate output 582. If this context is preempted or 
time-sliced at the same instruction cyde boundary (the 
master clock rising edge Mr 517) that the WAIT flip-flop 
578 is set, the context will not be running. Hence, the 
context running signal 556 will be negated prior to the 
next quadrature rising edge Qr 518. and the ACT flp- 
ftop 590 will remain set. When this context resumes run- 
ning, the ACT flip-flop 590 will be cleared at the quadra- 
ture clock rising edge Qr 518 of the first instruction cycle 
causing the context to become inactive after executing 
this one instruction. The negation of the ACT flip-flop 
output 590 clears the WAIT flip-flop 578 via the NOT 
inverter 592. 

[01 12] Turning now to FIGURE 1 1 , illustrated are field 
and bit assignments of machine instructions pertaining 
to context control and inter-context communication in 
the instruction set according to one embodiment of the 
present invention. The details of the instruction decod- 
ing and field encoding are not directly relevant to the 
present invention, and this figure is included primarily to 
illustrate the operand fields that provide information 
needed by the context controller. 
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[01 1 3] Testing of bits in the context event status regis- 
ter 94 is most efficiently accomplished using SKPx 
Instructions 600. These instructions perform a test 
under mask or bitwise comparison between a specified 
"condition group" (C-group) 604 of eight related signals 
and an eight-bit mask value 605 contained in the 
instruction word. If the condition specified by a test 
operation 603 is true, the instruction following the SKPx 
is skipped. Relevant to the present invention is C-group 
01 , an "EVENTS" groip 608 which is unaffected by the 
event mask and which tests the contents of the event 
status register 94 of the running context. 
[0114] A VECTO R instruction 6 1 0 is decoded from the 
same opcode 602 as the SKPx instructions but has a 
distinctive value in its "test operation" field 612. The 
other 10 bits of the VECTOR instruction word are a vec- 
tor base address 613 whose use is described below. 
[01 1 5] A SIGNAL instruction 620 is used to implement 
an inter-context software signaling function previously 
described. The SIGNAL instruction 620 is one of the 
processor control instructions based on the value of an 
extended opcode field 622 with a distinctive subdecode 
value 623. Two parameter fields are decoded within the 
context controller when a SIGNAL instruction is exe- 
cuted. A specified event number 624 identifies a partic- 
ular event to assert among the events associated with a 
specified context number 625. All events may be the tar- 
get of the SIGNAL instruction 620, but implementation 
details in particular instances of this context controller 
and connected event sources may make it difficult to 
allow the SIGNAL instruction 620 to assert certain con- 
ditions. 

[01 1 6] An ACK instruction 630 and an INIT instruction 
640 are formatted and decoded in a similar way to the 
SIGNAL instruction620 but have only one parameter 
field each. The ACK instruction 630 carries only an 
event number 624, because acknowledgment of a con- 
text's events is only permitted by code executing in the 
same context, so a context number parameter would be 
superfluous. An INIT instruction 640 cames only a con- 
text number 625 because the initialize function is 
directed to a context, not to an event associated with a 
context. 

[0117] A STROBE instruction 650 can generate a 
specified one out of as many as 32 discrete, imperative 
control functions 653. A WAIT instruction 654, is of rele- 
vance to the context controller, which clears the ACT bit 
of the running context; a SETFG instruction655, which 
sets the FG bit of the running context; a CLRFG instruc- 
tion 656, which clears the FG bit of the running context; 
and a SLEEP instruction 657, which causes the context 
controller to suspend operation and to allow the proces- 
sor to enter an extremely low-power sleep mode. 
[0118] The INIT instruction 640 is used to force the 
target context into a known state either for initialization 
or for error recovery. Execution of the INIT instruction 
640 sets both the ACT and FG bits to be logically true in 
the context specified in the instruction. It also sets a 



context CY (carry) flag to allow contexts to distinguish 
between hardware reset (when CY is equal to zero) and 
INIT (when CY is equal to one) and forces the context to 
begin executing at a context-specific initialization vector. 

5 [0119] Turning now to FIGURE 12, illustrated are 
sources of bits used to generate control store 
addresses on the processor according to one embodi- 
ment of the invention. The initialization vector address 
for a context-specific initialization vector mentioned 

10 above, may be formed by placing the contents of a con- 
text number field 625 of the INIT instruction 640 (of FIG- 
URE 11) into bit locations five through three of an 
address word containing all zeros as seen in an entry 
for an INIT Instruction 666 shown in FIGURE 12. 

15 [0120] Turning now to FIGURE 13, illustrated is an 
exemplary data structure diagram for initialization vec- 
tors in control store according to one embodiment of the 
present invention. As shown, this embodiment uses a 
set of eight initialization vectors 670-677 located at suc- 

20 cessive four-word intervals, control store address pat- 
tern 678 starting at control store address 0x0000. A 
four-word vector pitch was chosen because a long, 
absolute branch on this processor requires three words, 
and all but the last (context 7) vector 677 are likely to 

25 require such a branch. Requiring no branch for context 
7 is useful because context 7 is the sole context to be 
active after hardware reset. 

[0121] Therefore, the code at the context 7 initializa- 
tion vector is used to initialize the other contexts after 

30 hardware reset and for handling an INIT function to con- 
text 7. The vector pitch for use on other processors can 
be chosen in an embodiment-dependent manner. It is 
also desirable on some processors to use the contents 
of the initialization vector as an address which performs 

35 an indirect branch through the vector, rather than start- 
ing program execution at the vector address. The VEC- 
TOR instruction 610, shown in FIGURE 1 1 , is useful for 
priority-based decoding of the event(s) causing context 
activation. 

40 [0122] Turning now to FIGURE 14, illustrated is a dia- 
gram setting forth target address generation by vector 
instruction used to prioritize and decode specific context 
activation bits on the processor according to one 
embodiment of the present invention. As stated earlier, 

45 the VECTOR instruction 610 is useful for priority-based 
decoding of the event(s) causing context activation. 
When executed, this instruction branches to one of a set 
of eight handlers 680-687 in a vector table 690 located 
in control store. 

50 [01 23] A vector table base address 61 3 is specified in 
the ten lowest-order bits of the VECTOR instruction 
word 610. A specific vector is selected by priority encod- 
ing the context event status register 94 ANDed with the 
context event mask register 90. Then, using a resulting 

55 event number 694 as bit positions six through four along 
with a set of zeros 692 in bit positions three through 
zero of the vector address 678 (as seen in FIGURE 13) 
causes execution to continue at the beginning of the 
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eight-word handler location 680-687 assigned to the 
highest-priority (lowest-numbered) asserted non- 
masl^ed event. Because the VECTOR instruction 610 
shown In FIGURE 11 is normally used shortly after 
reactivation following a WAIT instruction 654, there is 5 
reason to expect that at least one non-masked event 
flip-flop will be true (equal to one). If this were not the 
case, the context would not have become active. How- 
&fer, it is possible to include a vector at Base+64 words 
688 for the case where no event bits are set. ip 
[0124] For the instruction set of the current embodi- 
ment, this vector pitch of eight words permits many han- 
dlers to fit entirely within the vector table requiring no 
branch while handling that event For embodiments 
which provide a vector decode function of this type, the is 
pitch may be chosen to achieve a balance between fit- 
ting the entire harxJIer set into the vector table and leav- 
ing substantial amounts of control store unused due to 
the handler areas being much longer than is generally 
required. 20 
[01 25] From the above, it is apparent that the present 
invention provides a context controller for managing 
multitasking in a processor and a method of operating 
the same. In one embodiment, the context controller 
includes: (1 ) a time slice instruction counter that counts 2S 
a number of instructions executed with respect to a 
given background task and (2) a background task con- 
troller that cyclicly executes a context corresponding to 
another background task when the number of instruc- 
tions executed equals a dynamically-programmable 30 
time slice value. 

Claims 

1. A context controller for managing multitasking in a 3S 
processor, comprising: 

a time slice instruction counter that counts a 
number of instructions executed with respect to 
a given background task; and 40 
a background task controller that cyclicly acti- 
vates a context corresponding to another back- 
ground task when said number equals a 
dynamically-programmable time slice value. 

45 

2. The context controller as recited in claim 1 wherein 
said time slice instruction counter initially contains 
said dynamically-programmable time slice value as 
a time slice for said given background task begins, 
said time slice instruction counter decrementing as 
said instructions with respect to said given back- 
ground task are executed. 

3. The context controller as recited in claim 1 or claim 
2 wherein said context controller places said proc- 
essor in an idle state when all of said background 
tasks are inactive. 



4. The context controller as recited in any of the pre- 
ceding claims wherein said background task con- 
troller is adapted to activate a context 
corresponding to a particular background task by 
vectoring to a software-selectable memory location. 

5. The context controller as recited in any of the pre- 
ceding claims further comprising a foreground task 
controller that activates contexts corresponding to 
foreground tasks based on priority and in response 
to events, said background task controller cyclicly 
activating contexts con-esponding to said back- 
ground tasks subject to activation of said contexts 
corresponding to said foreground tasks. 

6. Ttie context controller as recited in any of the pre- 
ceding claims wherein said dynamically-program- 
mable time slice value is contained in a register of 
said processor. 

7. The context controller as recited in any of the pre- 
ceding claims wherein application tasks executing 
on said processor can program said dynamically- 
programmable time slice value. 

8. A method of managing multitasking in a processor, 
corrprising the steps of: 

counting a number of instructions executed 
with respect to a given background task; and 
cyclicly activating a context corresponding to 
another background task when said number 
equals a dynamically-programmable time slice 
value. 

9. The method as recited in claim 8 wherein said step 
of counting comprises the steps of: 

initializing a time slice instruction counter with 
said dynamically-programmable time slice 
value as a time slice for said given background 
task begins; and 

decrementing said time slice instruction coun- 
ter as said Instructions with respect to said 
given background task are executed. 

10. The method as recited in claim 8 or claim 9 further 
comprising the step of placing said processor in an 
idle state when all of said background taste are 
inactive. 

11. The method as recited in any of claims 8 to 10 
wherein said step of cyclically activating comprises 
the step of vectoring to a software-selectable mem- 
ory location. 

12. The method as recited in any of claims 8 to 1 1 fur- 
ther comprising the step of activating contexts cor- 
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responding to foreground tasks based on priority 
and in response to events, said step of cyclically 
activating comprising the step of cydlcly activating 
contexts corresponding to said background tasks 
subject to activation of said contexts corresponding 5 
to said foreground tasks. 

13. The method as recited in any of claims 8 to 12 fur- 
ther comprising the step of storing said dynami- 
cally-programmable time slice value in a register of 10 
said processor. 

14. The method as recited in any of claims 8 to 13 fur- 
ther comprising the step of programming said 
dynamically-programmable time slice value with is 
application tasks executing on said processor. 

15. A processor, comprising: 

an instruction decoder that decodes instruc- 20 
tions received into said processor and corre- 
sponding to a plurality of tasks; 
a plurality of register sets, corresponding to 
said plurality of tasks, that contain operands to 
be manipulated; 2s 
an execution core, coupled to said instruction 
decoder and said plurality of register sets, that 
executes instructions corresponding to an 
active one of said plurality of tasks to manipu- 
late ones of said operands; and 30 
a context controller as claimed in any of claims 
1 to 7. coupled to said instruction decoder and 
said execution core, that manages multitasking 
with respect to said plurality of tasks. 

35 

16. The processor as recited in claim 15 wherein said 
processor forms a portion of a general-purpose 
computer. 
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FIG, 4A 



system lO.Conlroller ->-100 



/♦ BitStringS ft 16 bosed on BiLString from L105 •/ K 
syntype Cgroup = Integer constants OJ endsyntype; L 
syntjfpe Cond = Integer constonts 0:31 endsyntype; 
syntype CtxNum = Integer constants 0:7 endsyntype; 
syntype EventNum = Integer constants 0:7 endsyntype ; 
syntype InstAddr = Integer constonts 0:65535 endsyntype; 
syntifpe Instruction = BitStringIS mdsyntype ; 
sjfntype Offset = Integer constants -128:127 endsyntype; 
syntype Ybase = Integer constants 0:1023 endsyntype; 

/* Exported from ContexLControBer •/ 
remote osleep, csw, idle Booleon nodeloy ; 
remote context CtxNum nodekiy ; f* running context */ 
remote events BtStringS nodeloy ; /* C->group 01 */ 
remote nctx CtxNum nodeloy ; /♦ next context ♦/ 
remote mask BitStringS nodeloy ; /♦ &ent Mask reg ♦/ 

/♦ Exported from Dota.Path_flnd_Interfflce_Resources •/ 
remote slice Natural nodeloy ; /* insi cyckss per bg sUce */ 
remote im Booleon nodekiy ;/* true for execute cycles */ 



signol 

AckE«(CtxNum,£yentNuffl). [ 
AckIn$t(EventNuffl), 
BcInst(Cond.Offseti aeorCy(CtxNum). 
aeorFG. CSoddrflnstAddr). 

CSd(]to(Instniction), Csl(xid(CtxNum), 
CsStor<CtxNum), 
Event(CtxNum,EventNum), 
ExtEvent(CtxNum,EventNum). HfOsc, 
HwReset, IniUnsti(CtxNum}. 
InitSeq(CtxHum). LfOsc, 
L0odMosk(8itString8), Mr, llf, 
Or, Qf. Reset, SetCyjctxNum), 
SetFG. SignalInst(CtxNum,EventNum). 
SkpInst(C9roup,BltString8). Seep, 
Yeclnst(ybase). Wait. Woke ; 



Tone. 48 
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FIG, 5 



ClkCcU- 



,^140 



I block ContexLController [sleep] 
110 



154 

s 

ClkPri 



141 
/ 
CctlSeq 



CsLood, 
CsStore. 
InitSeq 



160 
/ 
PriSeq 



142 
/ 
InstCcti 



162 
/ 
InstPri 



152 



1(1) 



156 
/ 
akSyn 

rMr.1 
IjesetJ 



150-HEvenUynchroniZ€f t*^"^^^'"^ 
(1.1) [ExtEvent] 



158 
/ 



124 
Eventsin 



Mr. 

Uf, Or. 
Reset. 
Wake 



EvenLPrioritizer 

0.0 



[Event] 



SyncEvents 
166 



Acklnst, 

CleQrFG. 

IniUnst. 

LoodMask. 

SetFG, 

Signollnst, 

Sleep. Wait 



[Event] 



164 
/ 
PriOP 



AckEv, 

ClearCy, 

CsLood, 

CsStore, 

SctCy 



CcUOP 

\ 
143 
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FIG. 6 



process EvenLSynchronizer — 150 



1(1) 



sigMl EndMork, ResetMorlc ; |\ 
agnaiset EndMark. ExtEvent, 
Mr. Reset. ReseUlork ; 

del cf CtxNum : 
del el EventNum : 



\ 

202-4 ) 



204- 



HolcLEvents 



206x>Mr 
210x/^ 



\EndUark 
losetf 



212^ 



Poss_Events 



214 



218- 



222- 



ExtEvent 



Event 



201- 



/* This process synchronizes events originoting outside of [\ 
the DISC core to the leading edge of Mr. The ossertion of L\ 
each external event Is indicated by on ExtEvent signol. The 
parameto^ of the signd provide the target context and 
event numbers. 

ExtEvent signob ore saved in the process' input queue 
until receipt of signal Mr from the ClocLGenerator Mock. 
The end of the Input queue is marked ond oil ExtEvent 
signals queued oheod of the EndMork ore copied to Event 
signals and sent to the EvenLPrioritizer process, where 
ttiey ore handled ot the next Mr. ♦/ 
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J_ 



ExtEvent p«-208 



^2( 



Reset 

E 



-226 



/ ResetMork 
\ to self ^ 



-228 



^FIush_Ever>tsj^: 



EndMork 



-216 



ResetMork 



230 



-232 



Hold_Events J-^220 



|^Hold_Events j-^234 
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FIG. 7A1 



process EyenLPriorilcer'^152 



del oct KtStringB : |\ 
del c|, eurBg CtxNum ; 
del t\ htiXkm ; 
del eyllQsk, evStotus 

Array(Cb(Nutn, RtStringfi) : 
del f9 BitStiingS ; 
del k, I. pm CtxNum ; 
del sTieeCount Natural ; 
dclwlBitStringS; 
del idled BtStringS ; 



-250 



signal ResetMork ; [\^ 
agnalset 

Acidnst, CleorfG, 

Event, Initlnst, 

LoadMosk. 

Mr. Mf, Or. Reset. 

ReseUiark, SetFG. 

SgnaOnst, Sleep, 

Woit. Woke ; 



1(4) 



-251 



imported ien Boolean ; |N 
imported sRee Noturol : 

dd exported osieep, csw, kile Boolean ; 
dd ex|)orted ctx os context CbNum ; 
del exported events, mosk SitStn'ngS ; 
dd exported nctx CtxNum ; 



-252 



/* This process handles signols that alter event stote, [\ 
context activation state, or execution state (sleep, idle). 

While Running, events. Signol Instructions, ond boding the 
Event Mask are handled ot once; while Ack, Init, Sleep, 
Wait, and Set/Oeor FG ore held on the process input 
queue until Mr. At Mr of execute (ien=l) cycles, any 
queued instruction {max=l/qcle) is processed, the context 
number, event fkigs (C-group l) ond event mosk values 
are updated to reflect a possible context switch, and the 
sTice count is decremented if the running context is in 
bockground. At Or the acUvity flogs ore updoted, then the 
highest priority active (fg) context, or cttfrent/next (bg) 
context is selected for execution ot the next Mr. 
performing a context switch or going Idle, starting at Mf, 
as oppropriote. V 



V 

TO FIG. 7A2 
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FIG, 7A2 



FROM na 7A1 

A 



254- 



25e- 



258- 



260- 



act := 0x80, 
ctx := 7, 
fg := OxFF. 



«v«nts 


:= 0x00, 


waited 


:= 0x00, 


mask 


= 0x00, 



I 



curSg := 0. 
sliceCount := 
import(srtce) 



262 / 

X; 



264 



CleorCy(7) 



266- 



export 
asleep, csw, 
ctx, events. 



Vt;sli)a(i(7) 
V vifl PriSeq 

"- i^ Running ^ 



init K.255 



osleep := fohe, 

C3W := folse, -^957 

idle false 



evMask(0.1.2. 
3.4,5.6.7) 
:= 0x00, 

evStotus{0.1.2. "^259 
J.4.5,6.7) 
:=0x00 



idle, 

mosk, 

nctx 



^267 



(_> 



Reset 

t: 



272 
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ResetMork 
to Self 
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[niBh^nflls r^278 



ResetMork 
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FIG. 7C 



process Event_Priorit*zer-^i52 
Prioritize h^350 



3(4) 



Aciclnst 

(ef) N352 



360 



Wait 



(evStotus(prev)) 
(•l):=0 N354 



362 



I 



366^ Sleep 



waited(prev):= 1 



V380 



AckCy 
(prev, 



>564 
-r- 356 



I 



368 



X 



370 



woited(ctx) 



(=0) 



osleep := true 

I 



export asleep 



Sleep 



oct(ctx) := 0, 
woited{ctx) := 0 1X384 



374>Y" 



nr i 



c|:=0 



^386 



c# := 1 



^392 



oct(c# := 
if (evMask(c^) 



^388 

else 



(=7) 



"A else 



evStalus(cil)) = 0 
then oct(c|) 
else 1 fi 

S 

389 



^selX 
next/ 
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FIG, 7D1 

process EvcnLPrioritizer 
/ 

152 



420- 



422 



424- 



k := k + 1 




nctx := curBg, 






k := 0, 








1 := if 





423 

_Z_ 



{act(ctx)=0) or 
fg(cU)=0) then 
7 else ctx fi 



(=0) 



k < 1 



(fobe) 







curBg := 
(curflg + 1) 
mod 8 







(false) 



r 



notffgfcurBq)) \^^^ 
and oct(curB9j / (^ 



--432 



450 



nctx := curBg 



452 



cur6g=nctx 



r 





(true) 


^436 


^ Go_Idle 












>• 


/ 




/ 

438 


/ 

440 



{(false) 



(true) 



StorLCSW 



462 



I 



© 



I 



7" 

460 



Running 
458 



V 
TO FK. 702 
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FIG, 7D2 



0 



idie := 
csw := 


true, 
true 






export idle, csw 






/ CsS<we(ct3() 
V via all 
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Idle h-448 



A 



1 





(true) 


idle := 


false. 


csw := 


true 



export idle, csw 
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CsLoad 
(nctx) 
via all 



csw := 


true 






export csw 







CsLoad 

(nctx) ---478 
vio all 



Running -^472 



CsSave 
(ctx) 
via all 
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FIG, 13 

InlUalization Vectors ^678 
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Context 0 Inrtiaiizotion Vector I 


0000 


671 


Context 1 Initialization Vector I 


0004 


m-^ 


Context 2 InltializaUon Vector I 


0008 
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Context 3 InltializaUon Vector I 


0000 
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Context 4 Initialization Vecbr I 


0010 
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Context 5 Initiolization Vector I 


0014 
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Context 6 Initialization Vector I 


0018 
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Context 7 InitlaHzation Vector I 


0010 



39 



EP 0 942 365 A2 




40 



